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(54) Title: MANAGING NEGOTIATIONS BETWEEN USERS OF A COMPUTER NETWORK 

^ (57) Abstract: Negotiating between two or more online computer users, including a first user and a second user, with the objective of 
engaging in a mutually desirable online activity (e.g., instant messaging, online games, chat rooms, e-commerce) in an environment 
C^l having specified characteristics, can be accomplished by (a) issuing a proposal message from the first user to the second user, the 
J£) proposal message specifying the particular environmental characteristics desired by the first user; (b) issuing a first response from 
the second user to the first user, the response comprising an accept message indicating agreement with the proposal, a reject message 
indicating disagreement with at least one aspect of the proposal, or a counterproposal offering to change one or more aspects of the 
proposal; (c) if the second user issues a counterproposal, issuing a second response from the first user to the second user, the second 
!j response comprising an accept message indicating agreement with the counterproposal, a reject message indicating disagreement 
with at least one aspect of the counterproposal, or another counterproposal offering to change one or more aspects of the counter- 
Q proposal; and (d) repeating steps (b) and (c) until acceptance, rejection or cancellation occur, cancellation representing a withdrawal 
of a proposal or counterproposal. A user's misbehavior during a negotiation session can be objected to by others, thus potentially 
affecting the user's ability to access system resources. 
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MANAGING NEGOTIATIONS BETWEEN USERS OF A COMPUTER NETWORK 

Technical Field 
This invention relates to managing communications 
between users of a computer network. 

Background 

The rapid emergence of the Internet and the World Wide 
Web has created an environment in which anybody in the world 
who can connect to the Internet through a personal computer is 
generally able to access the universe of information that is 
available via Web sites. Electronic mail (a.k.a. e-mail) has 
also become ubiquitous due to its ease of use and its low cost. 

The emergence of these capabilities has been spurred by 
technological advances in various areas, including 
microprocessors (both computing speed and miniaturization^ 
computer operating systems and interfaces (e.g., Windows, 
Macintosh, and Unix), and Internet browsers (e.g., Netscape 
Navigator) . In turn, the rapidity of increase of the 
technology has had a direct positive impact upon productivity, 
and the world economy in general. Thus, there is an incentive 
for high-tech entities to create further improvements in the 
state of the art with respect to the Internet. 

An online forum is a communications interchange in which 
people may communicate with others through successive 
electronic transmissions between respective computer systems. 
An online forum, or any other type of distributed computer 
services, may be implemented on a distributed computer system 
such as that shown in FIG. 1. Forum participants 
(equivalently , users of the computer services) typically are 
scattered across a large geographical area and communicate with 
one or more central server systems 10 0 through respective 
client systems 102 (e.g., a personal or laptop computer). In 
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practice, the server system 100 typically will not be a single 
monolithic entity but rather will be a network of 
interconnected server computers, possibly physically dispersed 
from each other, each dedicated to its own set of duties and/or 
5 to a particular geographic region. In such a case, the 
individual servers are interconnected by a network of 
communication links, in known fashion. One such server system 
is "America Online" from America Online Incorporated of Virginia 
(AOL) . 

10 Each client system 102 runs client software that allows 

it to communicate in a meaningful manner with corresponding 
software running on the server system 100. The client systems 
102 communicate with the server system 100 through various 
channels, such as a modem 104 connected to a telephone line 106 

15 or a direct Internet connection using a transfer protocol such 
as Transfer Control Protocol/ Internet Protocol (TCP/IP) . The 
server system 10 0 is responsible for receiving input from the 
client systems 102, manipulating the collective body of input 
information (and possibly information from other sources) into 

20 a useful format, and retransmitting the formatted information 
back to one or more clients 102 for presentation on an output 
device, such as a display screen. 

A specific aspect of the Internet "culture" is the "chat 
room" phenomenon. A chat room is a virtual space (i.e., an 

25 electronic channel) in which some specific communications 
activity is ongoing. In some cases, the activity is an 
application, such as a computer game. In many other cases, the 
activity is a simple conversation, or "chat session", between 
the participants. Referring to FIG. 2, a chat room 200 is 

30 illustrated, in which the various participants 204 (e.g., 

"Allens9", " JOSHUAALEX" , etc.) may enter text which appears in a 
scrolling text window 2 02 on each participant's computer display 
screen. In the example in FIG. 2, the chat room 2 00 has 2 2 
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participants whose identities (or "screen names") are listed in 
a scrolling window 210. A participant 204 may respond to the 
comment of another participant 2 04 by entering a line of text 
in an edit box 206 and activating (e.g., by clicking with a 
5 pointer device, such as a mouse) a SEND button 2 08. In 

response, the text in the scrolling text window 202 scrolls 
upwards and the newly entered line of text is displayed at the 
bottom of the scrolling text window 202. In the illustrated 
example, the last participant to enter a comment was 

10 JOSHUAALEX, who typed "TEXAS" . 

The chat room 2 00 shown in FIG. 2 is "public", meaning 
that it is generally open to any user of the online service 
who accesses it, and it typically has multiple participants who 
were placed in the chat room by the computer- service provider 

15 and who most likely never have met or conversed with one 

another before. A comment by a participant in a public forum 
may be seen by all of the participants of the chat room. If a 
participant desires some privacy, that participant may open and 
enter a "private" chat room (for example, by clicking on a 

2 0 "Private Room" button 212) , and thereafter invite one or more 

other participants to enter the private chat room, which can be 
accessed exclusively by the originators and their invitees. 
Once in a private forum, participants may communicate with one 
another without fear that uninvited participants will be able 
25 to see their comments. It is also possible to have a semi- 
public chat room, which is open to a specified group of users. 

AOL has created the AOL Instant Messenger (AIM™) system. 
The AIM system allows a user to create an electronic messaging 

3 0 medium known as a "Buddy List"™ of others (such as friends and 

family) with whom the user often interacts while online and 
send instant messages (IMs) to those users. The AIM system 
automatically informs the user whenever a member of that user's 
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buddy list is online. Thus, the two buddies can communicate 
directly (i.e., chat) because they both are online and are 
aware of each other's presence. 

Another development by AOL in this arena is the concept 
5 of "Evil". This concept arose in recognition of the fact that 
users can and do abuse the privileges afforded them by the 
abilities to communicate instantly with others and to transmit 
large volumes of information. Such abuse may occur, for 
example, when a user sends messages having objectionable 

10 content, or when a user overuses the AIM system by sending 

excessive numbers of messages to other users. Another form of 
abuse occurs when a user sends files that contain large amounts 
of data to another user, so that when the recipient tries to 
open or download the files, or even perform other activities, 

15 the recipient's computer system is slowed down due to the 
processing of the received files. 

AOL's creation of the Evil concept is an attempt to 
remedy this and other types of abuse. If a user perceives that 
another user is behaving badly (e.g., repeatedly sending 

2 0 unwanted IMs) , the offended user can "evil", or warn, the 

misbehaving user, thereby increasing the misbehaving user's Evil 
level. The effect of eviling a user typically is small but 
cumulative. Over time, if a user has been eviled a sufficient 
number of times, that user's ability to use system resources 
25 (e.g., send IMs) will be deliberately slowed as a punishment. 
If the abuse continues and even more eviling occurs, the abuser 
eventually can be involuntarily logged off the computer 
network. The underlying notion is to promote computer 
etiquette and basic courtesy in the online (and particularly 

3 0 chat room) environment. Giving users the power to "evil" one 

another gives them the ability to create a self -policing 
society, thus alleviating the Internet Service Provider (ISP) 
from having to perform the policing function. Further details 
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on eviling techniques can be found in U.S. Serial No. 
09/076,483, filed May 13, 1998, entitled "Regulating Users of 
Online Forums", and U.S. Serial No. 09/076,484, filed May 13, 
1998, entitled "Self -Policing, Rate Limiting Online Forums", 
5 both of which are incorporated by reference. 

Although it is possible for a chat room to be completely 
free-form dialogue on any subject, it is common for chat rooms 
to be organized around a specific subject for discussion. The 
proliferation of the chat room phenomenon has created a need 

10 for a mechanism to optimally arrange a chat room environment to 
meet the needs of the users. For example, a given user might 
desire to have a private conversation with a specific group of 
three other users on a particular subject. Alternatively, the 
user might wish to play a particular computer game jointly with 

15 two friends, each located at a different remote site. 

Presently, if such a user wishes to engage in such activity, 
the user can either 1) find an existing chat room where the 
desired activity is ongoing and attempt to join in, but not 
necessarily having any control over the identities or number of 

20 other participants; or 2) send an IM or e-mail message to the 
other users with whom the user wishes to engage in the activity 
and invite them to do so. Typically, the inviting user will 
receive either no response at all (e.g., if the recipient 
ignores the invitation) or a binary response (i.e., yes or no) 

25 to the invitation. 

In light of the foregoing, the present inventors have 
recognized the need for a powerful and flexible negotiation 
mechanism, whereby users desiring to communicate or otherwise 
interact with each other can "bargain" with one another in order 

3 0 to agree ultimately upon a mutually acceptable communication 
(e.g., chat room) or other interaction (e.g., multiple user 
computer game) context. 

- 5 - 
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Summary 

Implementations may include various combinations of the 
following features. 

A protocol, referred to as the "Rendezvous" protocol, is 
5 designed to facilitate interactions between users of a computer 
network by transmitting a first user's proposal for an activity 
to another user. The proposal may include one or more 
parameters descriptive of the proposed activity. A response, 
such as an acceptance, a rejection, or a counterproposal, is 

10 received from the other user. Depending on the received 

response, the users may or may not selectively engage in the 
proposed activity. 

One such activity could be an online "chat" session, and 
a typical set of parameters for a proposal to chat could 

15 include a proposed topic on which the chat session will be 

focused and a proposed channel in which the chat session will 
take place. Another typical activity could be an online 
computer game, and the specified parameters could identify 
proposed participants in the game. 

20 An acceptance indicates agreement to all parameters of 

the proposal. A rejection indicates disagreement with at least 
one parameter of the proposal. A counterproposal indicates an 
offer to modify one or more of the proposal parameters. If a 
counterproposal is made, a further response to the 

25 counterproposal can be made, and this response also can be an 
acceptance, a rejection, or yet another counterproposal. This 
sequence may occur indefinitely until acceptance or rejection 
occurs . 

A cancellation of a proposal or counterproposal may be 
30 issued by the user that originally made the proposal or 

counterproposal, so long as this occurs prior to the receipt of 
a response. Typically, such a cancellation should include a 
reason for the cancellation. 
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In issuing a rejection, a user may indicate that the 
proposal is being ignored, either explicitly or implicitly (by 
inaction) . 

The protocol allows users to transmit messages, 
5 referred to as "Evil" messages, registering displeasure with 
any proposal, counterproposal, or acceptance. An Evil message 
has a cumulative (and potentially exponential) effect upon a 
recipient's ability to access the computer system's resources. 

One objective of the protocol is to help online users 

10 produce an optimal environment for an activity by enabling 
them to negotiate the parameters of the activity until 
agreement is reached. Typical activities include exchanging 
voice messages, playing an online game, finding a route from 
one client computer to another, transferring files, direct 

15 instant messaging, exchanging avatars, participating in a chat 
room, or engaging in collaborative project development. 

Another potential online activity that can make use of 
the Rendezvous protocol is e-commerce. The protocol lends 
itself to a negotiation of a sale/purchase of goods or 

2 0 services, or intangible property. Parameters of such a 

negotiation might typically include price, model, style, color, 
delivery details, and warranty details. 

A rejection message may indicate a reason for the 
rejection. Typical reasons include the following: the 

25 proposed activity is unsupported by a client computer 

associated with a recipient of the proposal; the proposed 
activity was denied by a recipient of the proposal; a recipient 
of the proposal explicitly ignored the proposal; the proposal 
timed out; or the proposal message could not be understood. 

30 In one embodiment, the Rendezvous protocol is 

implemented as computer software potentially within a larger 
computer software application. The protocol software is 
tangibly embodied in a computer -readable medium or propagated 
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carrier signal. The protocol software contains instructions to 
allow the computer system to conduct an online negotiation 
session. 

The techniques and mechanisms described here may provide 
5 one or more of the following advantages. The Rendezvous 
protocol provides users with the ability to negotiate 
characteristics of an interactive online environment (chat 
session, online game, etc.). As a result, users can tailor and 
optimize their online environments so that they are mutually 

10 agreeable to all participants. This optimization typically 
occurs prior to inception of the environment undergoing 
negotiation. Consequently, users can engage in environments of 
their own choosing and according to their own desires, and 
without encountering unwanted or undesirable circumstances or 

15 participants. 

Additional features and advantages will be apparent from 
the following description, including the figures and the 
claims . 

20 Brief Description of the Drawings 

FIG. 1 shows a prior art distributed computer system of 
the type used for providing online computer services. 

FIG. 2 is a screen shot showing an example of a prior 
art online computer chat room forum. 
25 FIG. 3 is a flowchart illustrating a protocol for a 

negotiation process. 

FIG. 4 is a table of state transition values. 
FIG. 5 is a diagram illustrating the data format of a 
negotiation protocol message. 
30 FIG. S is a table of data values for data fields in a 

negotiation protocol. 

FIG. 7 is a table of parameters for a TLV field within a 
negotiation protocol message. 
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FIG. 8 is a diagram illustrating a data format of a 
Client Error message. 

FIG . 9 is a table of data values for a Client Error Code 
data field. 

5 FIG. 10 is a screen shot showing an example of how a 

Chat proposal message appears to the online computer user who 
originates the proposal . 

FIG. 11 is a screen shot showing an example of how a 
Chat proposal message appears to the online computer user who 
10 receives the proposal. 

FIG. 12 is a screen shot showing an example of how a 
Client Error (rejection) message appears to the online computer 
user who rejects the proposal. 

FIG. 13 is a screen shot showing an example of how a 
15 Client Error (rejection) message appears to the online computer 
user who originated the proposal being rejected. 

FIG. 14 is a screen shot showing an example of how a 
File Transfer proposal message appears to the online computer 
user who receives the proposal. 
20 FIG. 15 illustrates an example of how a Direct Play 

(computer game) proposal message would appear to the online 
computer user who originates the proposal . 

FIG. 16 illustrates an example of how a Direct Play 
counterproposal message would appear to the online computer 

2 5 user who received the original proposal and who responds with a 

counterproposal . 

Like reference numbers and designations in the various drawings 
indicate like elements. 

3 0 Detailed Description 

The present inventors have developed a negotiation 
protocol - referred to as the "Rendezvous" protocol - that 
provides a mechanism for negotiating between two or more 
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computer users to arrange a mutually beneficial communication 
or multi-user interaction environment. One implementation of 
the Rendezvous protocol is in the AOL Instant Messenger (AIM) 
system, which allows users of a computer network to exchange 
5 instant messages (IMs) or to engage in a "chat" session, and 
further informs a user when any of that user's buddies are 
online in order to facilitate direct conversation. The 
Rendezvous protocol provides a general framework that software 
developers can use to implement various user-negotiation 

10 functionality in software applications. The AIM system, which 
allows users to chat, send IMs back and forth, and transfer 
files, represents one specific application of the Rendezvous 
protocol. In general, the Rendezvous protocol typically 
operates within the standard TCP/IP protocol, but any suitable 

15 protocol other than TCP/IP may be used instead. In this 
regard, protocols facilitating a reliable connection are 
preferable . 

The Rendezvous protocol adds a rich body of flexibility 
to the event of chatting or otherwise interacting with another 

20 user. It recognizes that a user may wish to engage in a 

particular activity under specific circumstances for example, 
playing a computer game with certain other players, or 
discussing a particular subject in a private chat room. 
Rendezvous uses "flea market - style" negotiation as a model for 

25 negotiating parameters of the interaction environment. Among 
others, the types of parameters that users may wish to control 
include the number of other participants and the identities of 
those participants. For example, perhaps a user enjoys playing 
bridge while online, but only with three specific individuals; 

3 0 or perhaps a user desires to communicate with other computer 
game enthusiasts about a new online game. The Rendezvous 
protocol allows a user to propose a communication session 
subject to such parameters. Further, Rendezvous allows 
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recipients of such proposals not only to accept or reject the 
proposal, but also to respond with a counterproposal that 
modifies one or more of the proposed parameters. 

The Rendezvous protocol serves as the underlying 
structure of the AIM system. A basic message between buddies 
in the AIM system is referred to as an Inter-Client Basic 
Message, abbreviated ICBM. ICBMs are said to contain 
"payloads," which hold the informational content of an ICBM. An 
Instant Message (IM) , which effectively is like an e-mail 
message that will be instantly displayed to the recipient, is 
an example of an ICBM payload. In general, a Rendezvous-based 
message is another example of an ICBM payload. (It is noted 
that there is one type of Rendezvous message, a Client Error 
message, to be described below, which is not an ICBM.) 

As discussed above, one characteristic of the AIM system 
is the ability to "evil" another user. A user might employ the 
evil capability against another user in an instance in which 
the user was annoyed by an action taken by that other user that 
affected the first user. For example, suppose that a first 
user sends a series of IMs to a buddy (a second user) , but 
after the third message, the buddy sends a message back 
requesting that the first user stop bothering the second user 
with all these boring messages. Despite this, the first user 
continues to send messages. The second user becomes annoyed 
and decides to evil, or warn, the sender. Evil can be employed 
generally on any ICBM. (It is noted that because a Client 
Error message is not an ICBM, it cannot be eviled for reasons 
discussed below.) 

A process for negotiating parameters using the 
Rendezvous protocol process is illustrated by the flowchart in 
FIG. 3. A user (referred to as "the originator") who wishes to 
interact with one or more other users, for example, to set up a 
particular chat room environment, begins the Rendezvous session 
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by sending a "Proposal" message to a buddy (step 3 01) . The 
Proposal message contains the originator's proposal for the 
desired interaction in this example, a specified chat room 
environment (e.g., topic, participants, etc.). 
5 If at any time after sending a Proposal message (but 

prior to the negotiation process ending as a result of some 
other event, such as acceptance or timeout by the recipient), 
the originator wishes to cancel the proposal, this may be 
accomplished by sending out a Cancel message (step 303) . A 

10 Cancel message allows the originator to provide a reason for 
the cancellation. The three valid types of Cancel reasons 
include "unknown", "user request", and "timeout". A normal 
cancellation, i.e., the originator changed his mind and does 
not desire to engage in an interaction, is denoted by 

15 specifying the Cancel reason as "user request". "Timeout" is 

given as the Cancel reason when the recipient fails to respond 
to the proposal in a timely manner and the originator gives up 
on waiting for a response and thus takes the proposal off the 
table. If the reason for the Cancel message is not known, the 

2 0 Cancel reason field will indicate "unknown". 

Assuming that the original proposal has not been 
cancelled, the recipient of the proposal may respond to the 
proposal in several different ways (step 3 05) . One way in 
which the recipient may respond is to accept the proposal 

2 5 exactly as proposed by sending an Accept message (step 3 07) . 
This will cause the Rendezvous session to end successfully and 
allow the proposal originator and the proposal recipient to 
engage in the desired interaction (e.g., chat room) activity. 
It is noted that for the above implementation, the only way 

30 that a Rendezvous session can end successfully (i.e., the 

parties engage in an online activity which was agreed to via 
the Rendezvous session) is by way of an Accept message. 
However, depending on the objectives of the application 
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developer, the Rendezvous protocol could be implemented such 
that other conditions (e.g., failure of recipient to object to 
a proposal under certain circumstances) could result in a 
successful termination. 
5 Another way for the recipient to respond is to reject 

the proposal by sending a Client Error message (step 3 09) . A 
Client Error message has a field that informs the originator of 
the reason for the rejection. Possible reasons include the 
following : 

10 1) Proposal unsupported (e.g., recipient's computer is 

not configured to support) 

2) Proposal denied 

3) Proposal ignored 

4) Proposal timed out 
15 5) Busted parameters 

6) Online but not available / busy 

"Proposal unsupported" is an appropriate reason when the 
recipient's computer is not configured properly in order to 

2 0 engage in the proposed interaction. "Proposal denied" is an 

explicit rejection of the proposal, indicating that the 
proposal recipient prefers not to engage in the interaction. 
"Proposal ignored" indicates that the recipient has actively 
chosen to ignore the proposal. "Proposal timed out" indicates 
25 that the recipient has failed to respond within a certain 

amount of time. "Busted parameters" denotes that the proposal 
message itself cannot be understood, e.g., if the proposal 
message became garbled in transmission and hence cannot be read 
by the recipient's computer. "Online but not available / busy" 

3 0 is the appropriate response when the recipient might otherwise 

be interested, but is too busy with other activities at that 
moment. For example, if the recipient is online because he is 
doing research for a project for work or school, and one of his 
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buddies proposes that they play an online computer game, the 
recipient would most likely respond with a Client Error message 
specifying the reason "Online but not available / busy". The 
recipient can accomplish this by setting a software switch that 
5 automatically responds with the "busy" message for each proposal 
received . 

It is noted that, in this implementation, a Client Error 
message is the only type of Rendezvous message that cannot be 
eviled. All other Rendezvous message types are subject to 

10 eviling. The reason for this design decision is that allowing 
"evil" simply because a user has refused to engage in some 
interaction does not serve the purpose of "evil", which is to 
warn a user for abusing the computer resources. However, the 
Rendezvous protocol could be implemented such that any one or 

15 more of the available messages could be subject to evil, or 
not, depending on the implementor's objectives. 

Another possible response by the recipient is to modify 
the proposal by sending a Propose message back to the 
originator (step 311) . This message contains a counterproposal 

20 by the recipient. This is the basic means by which the two 
parties haggle over the details of the resultant chat room or 
other interaction (e.g., one-on-one games) environment. For 
example, suppose user A desires to play an online computer game 
of bridge at the expert level with user B. User A proposes 

25 this to user B. However, user B prefers the intermediate level 
to the expert level, so user B sends a counterproposal to user 
A, proposing that the game be played at intermediate level 
instead. As a second example, suppose that user X and user Y 
are involved in a research project together, and they desire to 

30 enter a chat room in which their topic is often discussed. 
User X proposes to user Y that they meet together in a 
particular chat room that they have previously entered. 
However, user Y has heard about a different chat room that may 
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offer better information, so user Y sends a counterproposal 
back to user X that they instead meet in the new chat room. 

Once a counterproposal has been sent, the recipient of 
the counterproposal has the same options (i.e., Accept, refuse 
5 via Client Error message, or send another counterproposal via a 
Propose message) as the recipient of the original proposal had 
upon receiving the original proposal. That is, the 
counterproposal effectively is treated as a new proposal. The 
sender of the counterproposal has the option of cancelling the 

10 counterproposal via a Cancel message, just as the original 
proposer had the option of cancelling the original proposal. 
In this way, the Rendezvous session can continue back and forth 
until the users either agree on some online activity, or one of 
them decides to end the session via a Client Error message. 

15 A representation of the Rendezvous protocol is provided 

in the Rendezvous State Transition Table, shown in FIG. 4. The 
State Transition Table lists the three possible states of a 
Rendezvous session: State 1 is that of the proposal 
originator; state 2 is that of the proposal recipient, and 

20 state 3 is the end state, in which the Rendezvous session is 
terminated. Once a proposal is sent, thereby initiating a 
Rendezvous session, the proposal originator enters state 1 and 
the proposal recipient enters state 2 . 

In state 1, one of five possible events will occur; 

25 these are represented by the five substates within state 1. If 
an Accept message is received (i.e., substate 1.1), the 
Rendezvous negotiation is successful, and the users go to 
substate 3.1, where the Rendezvous session ends and the agreed- 
upon online activity begins. If a Client Error message is 

30 received (i.e., substate 1.2), the Rendezvous negotiation is 
unsuccessful, and the users go to substate 3.2, where the 
Rendezvous session ends and the users discontinue their 
interaction. If a counterproposal is received (i.e., substate 
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1.3), that user becomes the proposal recipient with respect to 
that counterproposal and thus enters state 2. If either a Time 
Out (substate 1.4) occurs, or a Cancel message is sent 
(substate 1.5), the negotiation session is cancelled by going 
5 to substate 3.3, where the Rendezvous session ends and the 
users discontinue their interaction. 

In state 2, four possible events can occur; these 
generally correspond with the five possible events listed in 
state 1 (the fourth event in state 2 (i.e., substate 2.4) 

10 corresponds to either of the fourth (substate 1.4) or fifth 

(substate 1.5) events in state 1). As the proposal recipient, 
the user in State 2 can send either an Accept message (substate 
2.1), a Client Error message (substate 2.2), or a 
counterproposal (substate 2.3). The fourth possibility is the 

15 receipt of a Cancel message (substate 2.4) . If an Accept 

message is sent, the Rendezvous negotiation is successful, and 
the users go to substate 3.1, where the Rendezvous session ends 
and the agreed-upon online activity begins. If a Client Error 
message is sent, the Rendezvous negotiation is unsuccessful, 

20 and the users go to substate 3.2, where the Rendezvous session 
ends and the users discontinue their interaction. If a 
counterproposal is sent, that user becomes the proposal 
originator and thus enters state 1. If a Cancel message is 
received, the negotiation session is cancelled by going to 

25 substate 3.3, where the Rendezvous session ends and the users 
discontinue their interaction. 

In state 3, the Rendezvous session ends in one of three 
ways. A successful negotiation, substate 3.1, occurs when an 
Accept message is sent in response to a Proposal message. In 

3 0 this case, the two users will engage in the agreed-upon online 
interaction. An unsuccessful negotiation, substate 3.2, occurs 
when a Client Error message is sent in response to a Proposal 
message. In this case, the users that were involved in the 
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Rendezvous session will discontinue their interaction. A 
cancelled negotiation, substate 3.3, occurs when a Cancel 
message is sent after a Proposal message was sent but prior to 
the receipt of a response. In this case, the users that were 
5 involved in the Rendezvous session will discontinue their 

interaction. In all three cases within state 3, the Rendezvous 
session is ended, as signified by the discontinued use of the 
Rendezvous "cookie", which is the unique identifier of that 
specific Rendezvous session. 

10 A diagram showing the components and format of a 

Rendezvous message (except for a Client Error message) is shown 
in FIG. 5. (Because a Client Error message is not an ICBM, it 
has its own format, described below.) Because a Rendezvous 
message is an ICBM payload, and because all ICBMs use the 

15 standard TCP/IP protocol, the first two fields 501 and 503 in a 
Rendezvous message (other than a Client Error Message) are the 
TCP/IP header and the ICBM header. The ICBM header identifies 
the message as being a Rendezvous message. The next field 505 
defines the Rendezvous Message Type and has a length of two 

2 0 bytes. Valid Message Types include Proposal, Cancel, and 

Accept. Valid data values for the fields shown in FIG. 5 are 
given in FIG. 6. As shown therein, the Message Type field can 
contain a "0" for a Proposal message, a "1" for a Cancel message, 
or a "2" for an Accept message. 

25 Referring again to FIG. 5, the next field 507 in the 

Rendezvous Message is eight bytes long and is called the 
Cookie. The Cookie serves as a unique identifier for a 
specific Rendezvous negotiation session; thus, all ICBMs that 
are part of the same Rendezvous session have the same Cookie, 

30 but a new Rendezvous session will have a new Cookie. The next 
field 509 is a 64-byte field called a UUID (Universal Unique 
Identifier) . This field specifies the type of service desired. 
Referring again to FIG. 6, there are seven standard types of 
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service that can be accessed with the Rendezvous protocol: "AOL 
Talk"; "Direct Play"; "File Transfer"; "Route Finder"; "Direct 
ICBM"; "Avatar Exchange"; and "Chat". Several of these services 
are available in AOL Instant Messenger Version 2.0. (It is 
5 noted that only the first twelve characters of the UUIDs are 
shown in FIG. 6. For all seven UUIDs given, the last twenty 
characters are 11D1-8222-444553540000 . ) "AOL Talk" refers to an 
AOL- compatible voice system that allows users to exchange audio 
messages with each other. "Direct Play" refers to playing an 

10 online computer game. "File Transfer" allows a computer file, 
such as a document, a spreadsheet, or a pictorial or graphical 
data file, to be transferred from one user to another. "Route 
Finder" allows users to find an Internet route for another 
application in a situation where a "firewall" is blocking the 

15 direct route to the desired application (e.g., if a user is 
online at the workplace, it is common for employers to set up 
firewalls software agents that block designated network 
traffic). "Direct ICBM" (i.e., sending ICBMs through a direct 
TCP/IP connection between the originator's and recipient's client 

2 0 computers) allows users to exchange IMs directly with each 

other without having to go through the primary server for the 
AIM system, thus affording more speed and more privacy. It is 
noted that the Direct ICBM capability causes the users to lose 
the ability to use the "Evil" capability, and it also removes 
25 the protection against computer hackers that is normally 

provided by the primary AIM server. The Direct ICBM capability 
also may experience problems in penetrating firewalls. "Avatar 
Exchange" allows a user to exchange an image that typically 
represents the user's on-screen personality. "Avatar" is the 

3 0 term for this image, and it can be any graphical depiction, 

such as a cartoon, a drawing, or a photograph. "Chat" refers to 
a typical online dialogue in a chat room; this is typically 
performed by typing messages and sending them back and forth. 
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The Rendezvous protocol is not limited to the seven 
standard service types described above. Possible 
implementations include allowing user, for example, by 
5 accessing a special purpose users interface, to create their 
own UUIDs and corresponding applications. 

Referring again to FIG. 5, the next field 511 is a set 
of ordered triples, each ordered triple consisting of a Type, a 
Length, and a Value; hence, this field is referred to as the 

10 "TLV" field. The TLV field includes up to 15 reserved 
parameters, plus the application- specif ic parameters. 
Referring to FIG. 7, which shows the 15 potential reserved 
parameters in the Type field and their corresponding numbers, 
the TLV field contains the information that is specifically 

15 being negotiated in the Rendezvous process. The first 
parameter in the TLV field is the "ICBM Channel" or 
equivalently, the "Rendezvous Channel". This parameter 
identifies the kind of ICBM being proposed, such as an online 
game or a chat . 

2 0 The next three parameters in the TLV field are called 

"Rendezvous IP Address", "Proposer IP Address", and "Verified IP 
Address". An IP address, or Internet Protocol address, is a 
unique identifier for any computer or virtual location on the 
Internet. The Rendezvous IP address is the IP address at 
25 which the proposed interaction would occur. The Proposer IP 
Address is the actual IP address of the originator's computer. 
The Verified IP Address is the IP address of the originator's 
computer as seen by the primary AIM server. The verified IP 
address is different from the actual IP address when, as is 

3 0 sometimes the case, the computer associated with the actual IP 

address is behind an Address Translating Firewall to provide 
some protection against unauthorized use (i.e., computer 
hacking) . In that situation, the use of a verified IP address 
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allows users behind the firewall to communicate with others by 
having any responses directed to the verified IP address, 
rather than to the Proposer (i.e., actual) IP Address. The 
verified IP address also prevents "spoofing", which is the 
5 practice of providing another user with a false IP address. 

The next parameter in the TLV field is called "Port", 
which is the value of the Transfer Control Protocol (TCP) port 
for the Rendezvous Channel. More generally, a "port" is a 
logical channel identifier used by TCP. 

10 The next two parameters in the TLV field are called 

"Download URL" and "Verify Download URL" (URL = Universal 
Resource Locator; its specification can be found at RFC 1738) . 

Download URL is an instruction to download the software or 
other data for whatever service is being proposed. Most 

15 Internet resources have a URL; URLs are commonly referred to as 
Web site addresses, although URLs can point to resources other 
than Web sites. As an example, if the users desire to play a 
computer game, such as bridge, the bridge software must be 
downloaded to their personal computer workstations in order to 

2 0 participate in the game. Verify Download URL has the same 

basic information content as the previous parameter, but it may 
be added by the primary AIM server for protective reasons. 

The next parameter in the TLV field is called "Sequence 
Number", which is a one-up counter that iterates for each 

25 proposal within a specific Rendezvous negotiation session 
(i.e., all proposals and counterproposals having the same 
Rendezvous Cookie) . The original proposal is given a sequence 
number equal to 1, the first counterproposal would be given a 
sequence number equal to 2, and so forth. 

30 The next parameter in the TLV field is called "Cancel 

Reason", which indicates the reason that a given Rendezvous 
negotiation session is being cancelled. Valid reasons 
(described above) include "unknown", "user request", and 
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"timeout". 

The next parameter in the TLV field is called 
"Invitation". This is an arbitrary text string and is generally 
used to communicate in human-readable language. For example, 
5 suppose user P desires to play a game of online chess with user 
Q. User P will send a Proposal message to user Q, and the 
Invitation might say, "Hey Q # how about a game of chess?" 

The last two reserved parameters in the TLV field are 
called "Invite Mime Character Set" and "Invite Mime Language". 

10 These parameters specify the character set and the language, 
respectively, that are used in the Invitation. Supported 
character sets include "US-ASCII", "ISO-8859-1" and "UNICODE-2- 
0". For the Mime protocol, valid values are specified by ISO 
63 9, ISO 3166, and RFC 1766. If desired, the country also may 

15 be included (e.g., English-UK). 

Lastly, referring once again to FIG. 5, the Rendezvous 
message contains a field 513 of application- specif ic 
parameters. The application- specific parameters also are part 
of the TLV field, but their Type field falls outside of the 

20 reserved range (i.e., the first 15 parameters). These 
parameters depend upon the application or service to be 
accessed. For example, different computer games that can be 
played online typically will have differing sets of parameters 
in this field. 

25 As noted above, a Client Error Message is specifically 

excepted from the standard Rendezvous message format because it 
is designed to be not subject to "Evil". Although it is not an 
ICBM, it is a related message type referred to as an "ICBM 
Client Error" message. As such, it has its own data format, 

30 which is illustrated in FIG. 8. The first two fields 801 and 
803 in any ICBM Client Error message are the TCP/IP header and 
the ICBM Client Error header. The next field 8 05 is the 
Cookie, which is the same value as in the Rendezvous messages 
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within the same Rendezvous session (i.e., the Client Error 
Cookie necessarily has the identical value as the Cookie in the 
Proposal message to which the Client Error message is 
responding) . The next field 807 is called ICBM Channel, which 
5 is the value of the channel on which the Rendezvous negotiation 
itself is occurring (usually equal to 2) . (It is noted that in 
the Client Error context, the ICBM Channel field is different 
from the parameter of the same name in the TLV field of the 
Rendezvous message, where the ICBM Channel parameter refers to 

10 the channel where the proposed interaction would occur, not the 
channel where the Rendezvous negotiation itself is occurring.) 

The last field 809 is the Client Error Code. Referring 
to FIG. 9, the possible values for the Client Error Code are 
given. These values correspond with the six possible reasons 

15 for a Client Error message, described above. 

FIGs. 10 , 11, 12, 13, and 14 show examples of screen 
shots as seen by users of AIM during Rendezvous-related 
negotiations. As noted above, AIM is one specific 
implementation of the Rendezvous protocol. FIG. 10 shows how a 

20 proposal message 1000 appears to the originator. In FIG. 10, 
the proposed activity is a chat, and the screen name 1002 of 
the intended recipient is "yipster666" . The proposal message 
1000 is transmitted to the recipient when the originator clicks 
on the "Send" button 10 04 in the lower right-hand corner of the 

2 5 message box. 

FIG. 11 shows the proposal message 1100 as it appears to 
the recipient. The message box 1102 shows the screen name 1104 
of the proposal originator (in this case, " j imgromada") , the 
intended activity 1106 (a "Buddy Chat") the channel or location 

3 0 1108 of the proposed activity (a chat room named "jag Chat 00") , 

and the textual invitation line 1110, "Join me in this Buddy 
Chat". The recipient has the option of accepting the proposal 
by clicking on the "Go Chat" button 1112 in the lower right-hand 
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corner, rejecting the proposal by clicking on the "Decline" 
button 1114, or causing the proposal to time out by not 
responding. (The option of modifying the proposal by 
presenting a counterproposal is not illustrated by this screen 
5 shot . ) 

FIG. 12 shows a pop -up window 12 00 that appears when the 
recipient decides to reject the proposal. This is the message 
box that appears on the recipient's screen as a result of 
clicking on the "Decline" button 1114. This "Decline Invitation" 

10 message 1200 will be transmitted to the proposal originator 

when the proposal recipient clicks on the "OK" button 1202. If 
the recipient wishes to "evil" the originator because the 
proposal is deemed offensive or annoying, the recipient may do 
this by clicking on the "Warn" button. The block button 1206 

15 allows the receipt to block future proposals from this 
originator (jimgromada) . 

In FIG. 13, the proposal originator has received the 
rejection message 13 00 from the proposal recipient. Because 
this rejection message 1300 is by definition a Client Error 

2 0 message type, the proposal originator does not have the 

opportunity to "evil" the recipient, even though the proposal 
was rejected. The only option available to the proposal 
originator is to click the "OK" button. 

FIG. 14 shows a screen shot of a window 14 0 0 that 

25 appears when a user receives a file transfer request from 

another user. File Transfer is one of the activities supported 
by the Rendezvous protocol. The recipient may either accept 
the file transfer request by clicking on "OK" 1402, or reject 
the request by clicking on "Cancel" 1404, corresponding to an 

30 acceptance and rejection, respectively, of the proposal (i.e., 
file transfer) . 

In FIG. 15, a depiction of an online computer game 
proposal message 1500 is shown. The proposal originator 15 02, 
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User_A, desires to play a particular game 1504 (contract 
bridge) at an expert level 1510 with participants 1506 (User_A 
and User_B) . FIG. 15 illustrates how the proposal message 
would look as received by User_B, who has the opportunity to 
5 respond by clicking on the appropriate button at the bottom of 
the message box. If User_B is offended by the proposal, this 
can be registered by clicking on the "Warn" button 1512. If 
User_B would like to accept the proposal as tendered, the 
"Accept" 1514 button should be clicked. If User_B does not wish 

10 to play online bridge at all, the "Decline" button 1516 should 
be clicked (or the proposal will eventually be declined by 
timeout if User_B does not click on any buttons) . If User B 
wishes to play but disagrees with one or more of the parameters 
shown (e.g., game 1504, participants 1506, type 1508, level 

15 1510) , the "Modify" button may be clicked to allow User_B to 
present a counterproposal . 

FIG. 16 shows how such a counterproposal box 16 00 might 
appear to the user desiring to modify the original proposal 
(i.e., User_B in the example depicted in both FIG. 15 and FIG. 

2 0 16) . The originator 1602 is now User_B, because a 

counterproposal acts as a new proposal, and User_B is 
originating the counterproposal. It is noted that, because 
this counterproposal is part of the same Rendezvous negotiation 
session, the Cookie for the original proposal will be the same 

2 5 as the Cookie for the counterproposal. However, the Sequence 
Number for the original proposal will be equal to 1, and the 
Sequence Number for the counterproposal will be equal to 2. 
Both the Cookie and the Sequence Number are software parameters 
that are transparent to the users involved in the Rendezvous 

30 negotiation session. 

Referring again to FIG. 16, User_B agrees that playing 
online bridge with User_A is desirable. However, User_B 
prefers a different type 1608 of bridge (duplicate bridge) 
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rather than contract bridge, and User_B also prefers to play at 
the intermediate level 1610 rather than the expert level. 
Thus, these parameters have been modified in the 
counterproposal message box 1600, which will be sent back to 
5 User_A. User_A will then have the same options for responding 
(i.e., Warn, Accept, Decline, or Modify), and the Rendezvous 
negotiation session will continue in that manner until it ends 
either with an acceptance (i.e., recipient of most recent 
proposal clicks "Accept"), a rejection (i.e., recipient of most 
10 recent proposal clicks "Decline"), or a cancellation (i.e., 
sender of most recent proposal cancels by clicking a "Cancel" 
button after sending proposal but before receiving response) . 

Other implementations of and uses for the Rendezvous 

15 protocol described above are possible. In general, the 

Rendezvous protocol can be used whenever it is desirable to 
allow two or more users, or two or more client computers, to 
negotiate the parameters of a communication or interaction 
session. For example, the Rendezvous protocol could be used in 

20 e-commerce applications to allow buyers and sellers to haggle 
over price or other terms relating to an offer for the sale of 
goods, services, securities or any other tangible or intangible 
property. In addition, the Rendezvous protocol could be used 
in a collaborative project development environment (e.g., Lotus 

25 Domino) to negotiate changes to documents and the like. 

The techniques, methods and systems described here may 
find applicability in any computing or processing environment 
in which electronic content may be exchanged, viewed, accessed 
or otherwise manipulated. Various implementations of the 

3 0 systems and techniques described here may be realized in 
digital electronic circuitry, or in computer hardware, 
firmware, software, or in combinations thereof. A system or 
other apparatus that uses one or more of the techniques and 
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methods described here may be implemented as a computer- 
readable storage medium, configured with a computer program, 
where the storage medium so configured causes a computer system 
to operate on input and/or generate output in a specific and 
5 predefined manner. Such a computer system may include one or 
more programmable processors that receive data and instructions 
from, and transmit data and instructions to, a data storage 
system, and suitable input and output devices. 

Each computer program may be implemented in a high-level 

10 procedural or object-oriented programming language, or in 

assembly or machine language if desired; and in any case, the 
language may be a compiled or interpreted language. Suitable 
processors include, by way of example, both general and special 
purpose microprocessors. 

15 Generally, a processor will receive instructions and 

data from a read-only memory and/or a random access memory. 
Storage devices suitable for tangibly embodying computer 
program instructions and data include all forms of non-volatile 
memory, including semiconductor memory devices, such as EPROM , 

20 EE PROM , and flash memory devices; magnetic disks such as 

internal hard disks and removable disks; magneto-optical disks; 
and CD-ROM disks. 

Any of the foregoing may be supplemented by, or 
implemented in, specially-designed ASICs (application- specific 

25 integrated circuits) . 

A number of embodiments of the present invention 
have been described. Nevertheless, it will be understood that 
various modifications may be made without departing from the 
spirit and scope of the invention. Accordingly, other 

3 0 embodiments are within the scope of the following claims. 

What is claimed is: 
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1 1. A computer- implemented method of facilitating 

2 interactions between users of a computer network, the method 

3 comprising: 

4 transmitting a first user's proposal for an activity to 

5 another user; the proposal comprising one or more parameters 

6 descriptive of the proposed activity; 

7 receiving a response from the other user, the response 

8 comprising an acceptance, a rejection, or a counterproposal; 

9 and 

10 selectively engaging in an activity depending on the 

11 received response. 

1 2 . The method of claim 1 wherein the proposed activity 

2 comprises a chat session. 

1 3 . The method of claim 2 wherein the parameters 

2 describe a proposed topic on which the chat session will be 

3 focused. 

1 4 . The method of claim 2 wherein the parameters 

2 describe a proposed channel in which the chat session will take 

3 place. 

1 5 . The method of claim 1 wherein the proposed activity 

2 comprises an online game. 

1 6 . The method of claim 5 wherein the parameters specify 

2 proposed participants in the proposed online game. 

1 7 . The method of claim 1 wherein an acceptance 

2 indicates agreement to all parameters of the proposal. 

1 8. The method of claim 1 wherein a rejection indicates 
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2 disagreement with at least one parameter of the proposal. 

1 9 . The method of claim 1 wherein a counterproposal 

2 indicates an offer to modify one or more of the proposal 

3 parameters . 

1 10. The method of claim 1 wherein the parameters are 

2 completely descriptive of the proposed activity. 

1 11. The method of claim 1 wherein the response from the 

2 other user comprises a counterproposal, said counterproposal 

3 comprising one or more parameters descriptive of the proposed 

4 activity, and wherein at least one of the counterproposal 

5 parameters differs from the proposal's parameters. 

1 12. The method of claim 11 further comprising 

2 transmitting a response to the counterproposal, the 

3 counterproposal response comprising an acceptance, a rejection, 

4 or a second counterproposal. 

1 13 . The method of claim 12 further comprising 

2 iteratively responding to further counterproposals until 

3 acceptance or rejection occurs. 

1 14 . The method of claim 1 further comprising issuing a 

2 cancellation of a proposal or counterproposal. 

1 15. The method of claim 14 wherein the cancellation 

2 must be issued before acceptance or rejection of the proposal 

3 or counterproposal occurs. 

1 16. The method of claim 15 wherein the cancellation is 

2 transmitted by the user that transmitted the proposal or 

3 counterproposal to which the cancellation applies. 
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1 

2 17. The method of claim 16 wherein the cancellation 

3 includes a reason for the cancellation. 

1 18. The method of claim 1 wherein the response can 

2 further comprise an ignore indication. 

1 19. The method of claim 18 wherein receipt of the 

2 ignore indication acts as a rejection of the proposal or 

3 counterproposal . 

1 20. The method of claim 18 wherein the ignore 

2 indication is issued based on an explicit act by a user. 

1 21. The method of claim 18 wherein the ignore 

2 indication is issued based on inaction by a user. 

1 22. The method of claim 1 further comprising 

2 transmitting a message registering displeasure with any 

3 proposal, counterproposal, or acceptance. 

1 23 . The method of claim 22 wherein the message 

2 registering displeasure comprises an "Evil" message. 

1 24. The method of claim 23 wherein an Evil message has 

2 a cumulative effect upon a recipient's ability to use the 

3 computer network. 

1 25. The method of claim 24 wherein the cumulative 

2 effect grows exponentially. 

1 26. A computer -implemented method of producing an 

2 optimal environment for an online activity involving two or 
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3 more computer network users, the method comprising: 

4 allowing a first user to send a proposal for an online 

5 activity to one or more other users, the proposal specifying 

6 parameters associated with the proposed online activity; and 

7 enabling the first user and one or more other users to 

8 negotiate the parameters of the proposal until an agreement is 

9 reached. 

1 27. The method of claim 26, wherein the online activity 

2 comprises one or more of the following activities: exchanging 

3 voice messages, playing an online game, finding a route from 

4 one client computer to another, transferring files, direct 

5 instant messaging, exchanging avatars, or participating in a 

6 chat room . 

1 28. The method of claim 26, wherein the online activity 

2 comprises e- commerce. 

1 29. The method of claim 26, wherein the online activity 

2 comprises a collaborative effort on a project. 

1 30. The method of claim 26 wherein allowing a first 

2 user to send a proposal is implemented using a negotiation 

3 protocol . 

1 31. The method of claim 26 wherein negotiating 

2 parameters of the proposal comprises selectively exchanging one 

3 or more counterproposal messages until an acceptance or a 

4 rejection occurs. 

1 32 . A negotiation protocol for facilitating 

2 interactions between users on a computer network, the protocol 

3 comprising: 
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4 a proposal message type including parameters descriptive 

5 of a proposed activity; 

6 an acceptance message type indicating agreement with all 

7 parameters of a proposal; 

8 a rejection message type indicating disagreement with at 

9 least one of a proposal's parameters; and 

10 a cancel message type for withdrawing a proposal issued 

11 in a previous proposal message. 

1 33. The negotiation protocol of claim 32 wherein the 

2 proposal message type can be used to issue a counterproposal 

3 message in response to a received proposal message, the 

4 counterproposal message including at least one parameter that 

5 differs from the proposal message's parameters. 

1 34. The negotiation protocol of claim 32 wherein the 

2 proposal, acceptance, rejection and cancel message types can be 

3 used to negotiate the parameters of one or more of following 

4 activities: exchanging voice messages, playing an online game, 

5 finding a route from one client computer to another, 

6 transferring files, direct instant messaging, exchanging 

7 avatars, or participating in a chat room. 

1 35. The negotiation protocol of claim 32 wherein the 

2 rejection message type indicates that the proposed activity is 

3 unsupported by a client computer associated with a recipient of 

4 the proposal . 

1 36. The negotiation protocol of claim 32 wherein the 

2 rejection message type indicates that the proposed activity was 

3 denied by a recipient of the proposal. 



37. The negotiation protocol of claim 32 wherein the 
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2 rejection message type indicates that a recipient of the 

3 proposal explicitly ignored the proposal. 

1 38. The negotiation protocol of claim 32 wherein the 

2 rejection message type indicates that the proposal timed-out. 

1 39. The negotiation protocol of claim 32 wherein the 

2 rejection message type indicates that the proposal message 

3 could not be understood. 
1 

2 40. A computer-based system for facilitating 

3 interactions among users of a computer-network, the system 

4 comprising: 

5 two or more client computers having software that allows 

6 different users to interact with each other; and 

7 a negotiation protocol, supported by each of the client 

8 computers, that allows users to negotiate parameters of an 

9 online activity. 

1 41. The system of claim 40 in which the software on the 

2 client computers enables users to interact in one or more of 

3 the following activities: exchanging voice messages, playing an 

4 online game, finding a route from one client computer to 

5 another, transferring files, direct instant messaging, 

6 exchanging avatars, or participating in a chat room. 

1 42. The system of claim 40 in which the client computer 

2 software comprises an instant messaging client application. 

1 43. The system of claim 40 in which the negotiation 

2 protocol comprises the following message types: 

3 a proposal message type including parameters descriptive 

4 of a proposed activity; 
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5 an acceptance message type indicating agreement with all 

6 parameters of a proposal; 

7 a rejection message type indicating disagreement with at 

8 least one of a proposal's parameters; and 

9 a cancel message type for withdrawing a proposal issued 
10 in a previous proposal message. 

1 44. The system of claim 43 in which negotiation 

2 protocol messages are exchanged among users until mutually 

3 agreeable parameters of an online activity are established. 
1 

2 45. The system of claim 40 further comprising a 

3 software- implemented mechanism for registering displeasure with 

4 a user's behavior during a negotiation session. 
5 

6 46. The system of claim 45 wherein the mechanism for 

7 registering displeasure enables a user to affect another user's 

8 ability to access system resources. 
9 

10 47. A computer protocol process for conducting a 

11 negotiation between two or more online computer users, 

12 including a first user and a second user, with the objective of 

13 engaging in a mutually desirable online activity in an 

14 environment having specified characteristics, the process 

15 comprising: 

16 (a) issuing a proposal message from the first user to 

17 the second user, the proposal message specifying the 

18 particular environmental characteristics desired by the 

19 first user; 

20 (b) issuing a first response from the second user to the 

21 first user, the response comprising an accept message 

22 indicating agreement with the proposal, a reject message 

23 indicating disagreement with at least one aspect of the 
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24 proposal, or a counterproposal offering to change one or 

25 more aspects of the proposal; 

26 (c) if the second user issues a counterproposal, issuing 

27 a second response from the first user to the second 

28 user, the second response comprising an accept message 

2 9 indicating agreement with the counterproposal, a reject 

30 message indicating disagreement with at least one aspect 

31 of the counterproposal, or another counterproposal 

32 offering to change one or more aspects of the 

33 counterproposal; and 

34 (d) repeating steps (b) and (c) until acceptance, 

35 rejection or cancellation occur, cancellation 

36 representing a withdrawal of a proposal or 

37 counterproposal . 

1 48. A computer -implemented method of facilitating e- 

2 commerce transactions between users of a computer network, the 

3 method comprising: 

4 transmitting to another user a first user's proposal for 

5 an e-commerce transaction; the proposal comprising one or more 

6 parameters descriptive of the proposed transaction; 

7 receiving a response from the other user, the response 

8 comprising an acceptance, a rejection, or a counterproposal; 

9 and 

10 selectively completing the proposed transaction 

11 depending on the received response. 

1 49. The method of claim 48, wherein the e-commerce 

2 transaction comprises a sale/purchase of goods/services. 

1 50. The method of claim 48, wherein the e-commerce 

2 transaction comprises a sale/purchase of intangible property. 
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1 51. The method of claim 48, wherein the parameters of 

2 the proposal comprise price, delivery details, model, style, 

3 color, and warranty details. 

1 52. Computer software, tangibly embodied in a computer- 

2 readable medium or propagated carrier signal, for facilitating 

3 interaction among users of a computer network, the software 

4 comprising instructions for causing a computer system to 

5 perform the following operations: 

6 allow a first user to send a proposal for an online 

7 activity to one or more other users, the proposal specifying 

8 parameters associated with the proposed online activity; and 

9 enable the first user and one or more other users to 

10 negotiate the parameters of the proposal until an agreement is 

11 reached. 
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1400 



g Receive File from PhillipsJC 



WARNING! You have received a file transfer request! If 

you don't know who is sending you this file, be cautious, it 
could contain a computer virus. Computer viruses can destroy 
your work and even damage your computer. 

AOL Instant Messenger (SM) Anti-virus Center: 



How can I protect my computer? 

1 . Get anti-virus software, and use it. 

2. Don't open file transfers from strangers. 

3. Update your anti-virus software regularly. 

4. Make back-ups of your important files regularly. 

5. Run your own virus-check on any file someone sends you. 

6. If you exchange floppy disks, virus-check your floppies. 

Some Leading Anti-virus Software: 

Norton Antivirus V5.0 for Windows 95/98 
VirusScan Classic V4.0 

Dr. Solomon's Anti-Virus Deluxe Windows 95/NT 
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